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What is MILITRAN? 

MILITRAN is a simulation-oriented, general purpose 
language developed by GULTON SYSTEMS RE¬ 
SEARCH GROUP, INC. under the sponsorship of the 
Office of Naval Research. The primary purposes of 
MILITRAN are: 

1. To facilitate the design of a simulation model to 
be implemented on a digital computer, 

2. To reduce the time and expense necessary to pro¬ 
gram the simulation model, and 

3. To assist in the extraction of meaningful results 
from the simulation. 

The structure of the MILITRAN language is grounded 
in a methodology common to all simulations and thus*! 
offers the analyst a natural vehicle for the expression# 
of his model. This same language lends itself to straight- 1 
forward programming techniques without the need for (I 
elaborate circumlocutions. 

Every effort has been made to make the language 
natural from the point of view of both analyst and pro¬ 
grammer. For example, matrices and other arrays may 
be indexed explicitly on the name of an object; SPEED 
(THRESHER) and SPEED (SEA WOLF) correctly 
specify the appropriate entries of the vector SPEED 
without the assignment of artificial numerical values to 
the submarines named. Arrays having up to ten dimen¬ 
sions are permitted, thus eliminating the need for artificial 
partitioning to meet language limitations. Names of 
parameters may be up to sixty characters long; for 
example, NUMBER OF SUBMARINES IN THE 
NORTH SEA is a perfectly valid parameter name, easily 
understood by both programmer and analyst. Cryptic 
abbreviations are no longer needed. This flexibility, built 
into the MILITRAN language, reduces the difficulties 
associated with analyst/programmer communication; the 
program follows naturally from the analyst’s model and 
the analyst can easily interpret and check the actual pro¬ 
gram statements. 

All of the general processing and computational fea¬ 
tures familiar to users of FORTRAN, JOVIAL, and 
other algorithmic languages are present in MILITRAN 
in addition to the special simulation features. Simulations 
often contain a great deal of straightforward computation 
and data handling, and to provide special features at the 
expense of general power would be robbing Peter to pay 
Paul. Some users have stated that they find MILITRAN, ^ 
because of its great flexibility, ideal for non-simulation ? 
work involving purely computational programming. The L 
primary purpose of MILITRAN’s general programming*, 
features remains, however, the reduction of effort re- w 
quired to program simulations. The following pages are 
devoted to discussions of specific MILITRAN features. 


Objects 

In defining the elements of a simulation model, the 
analyst frequently finds it convenient to refer to abstract 
objects (submarines, missiles, passengers, telephone 
lines, etc.) as well as to purely numerical parameters. 
These objects may further be grouped into classes, asso¬ 
ciated with other objects, or have numerical character¬ 
istics describing them. A conventional programming 
language would either force the analyst to specify his 
model in an unnatural way or compel the programmer 
to develop a scheme of artificial numerical codes, flags, 
and indices. MILITRAN allows any natural system 
definition to be programmed directly. 

In addition to the usual numerical and logical vari¬ 
ables, the MILITRAN programmer may use PRO¬ 
GRAM OBJECT variables to manipulate abstract ob¬ 
jects. The two statements below are analogous: 

ATTACKER = SEA WOLF 
I — 5 

The first statement assigns the value “5” to the numerical 
variable “I” while the second assigns the value “SEA 
WOLF” to the PROGRAM OBJECT variable 
“ATTACKER.” PROGRAM OBJECT variables may 
be used with essentially the same freedom as numerical 
variables—they may be compared, used in logical con¬ 
ditions, placed in vectors and other arrays, used as sub¬ 
scripts or indices, formed into lists, etc. The MILITRAN 
statements below illustrate some of these operations. 

OBJECT PLYMOUTH(2), RAMBLER(3), CADILLAC(l), ROLLS(2) 

defines eight cars as basic objects in the system. 

CLASS (LUXURY) CONTAINS EACH*CADILLAC, EACH*ROLLS 

defines a class or group containing the one CADILLAC 
and the two ROLLS. The class is called LUXURY. 

PROGRAM OBJECT MY CAR 

defines MY CAR as a program object variable. 

MY CAR = RAMBLER(l) 

assigns the value “RAMBLER” to the program object 
variable, “MY CAR.” In particular, MY CAR is now 
the first of the three Ramblers defined above. 

IF (MY CAR . IN . LUXURY), HOME JAMES 

tests the current value of MY CAR. If that value is a 
member of the class LUXURY, control will transfer to 
the statement labelled “HOME JAMES.” 

Numerical values may be associated with either objects 
or classes. Given the definitions 

CLASS (ECONOMY) CONTAINS EACH*R AMBLER, EACH*PLYMOUTH 
CLASS (CAR) CONTAINS EACH*LUXURY, EACH*ECONOMY 
INTEGER HORSEPOWER (CAR), SPEED (CAR) 

we could immediately refer to the values of SPEED (MY 
CAR) and HORSEPOWER(MY CAR) without resort 
to artificial indexing schemes. 




List Processing 


Events 


In the design of a simulation model it is often con¬ 
venient to think of groups of related data as entries in 
a list. For instance, the position, assigned target, and 
weapon load of an aircraft in flight might constitute an 
entry in a “strike” list. So many similar groupings occur 
in the average simulation model that list processing fea¬ 
tures are especially helpful in a simulation language. 

MILITRAN provides an extensive list processing 
capability. The statements provided for defining and 
processing lists are both flexible and powerful. Lists may 
be defined by LIST statements. The number and types 
of items included in a single list entry is entirely pro¬ 
grammer-defined; numerical, logical, and program object 
information may be combined in any way within a list 
entry. List entries may be created by PLACE and 
PLACE ENTRY statements; modified by REPLACE 
and REPLACE ENTRY statements; located by the sys¬ 
tem functions MINIMUM INDEX and RANDOM 
INDEX; and destroyed by means of REMOVE and 
REMOVE ENTRY statements. The entry or entries to 
be modified or removed by a REMOVE or REPLACE 
may be specified by logical conditions of any complexity 
on any or all components. This permits complex updating 
processes to be accomplished by a single MILITRAN 
statement. 

The flexibility of MILITRAN list processing is best 
demonstrated by example: 

LIST OPERATING ( (VEHICLE, DESTINATION, PASSENGERS), CAR) 

PROGRAM OBJECT VEHICLE, DESTINATION 

INTEGER PASSENGERS 

The above statements define a list and indicate the nature 
of information stored in each component of its entries. 
The use of “CAR” as a dimension indicates that the 
maximum number of entries possible is the number of 
objects in the class “CAR.” 

Operations on the above list might include some of 
the following: 

PLACE (MY CAR, CHICAGO, 3) IN OPERATING 

records the status of a car carrying three passengers to 
Chicago. 

REPLACE (MY CAR) BY (*, NEW YORK, M) IN OPERATING 

updates the status of that car after dropping one passen¬ 
ger. 

REPLACE (,, * . L . 6) BY (*,*,* + 1) IN OPERATING 

adds one passenger to every car in the list which is now 
carrying less than six passengers. 

REMOVE (, LOS ANGELES) FROM OPERATING 

causes every entry whose DESTINATION is “LOS 
ANGELES” to be removed from the list. 

REPLACE ( ) BY (* , WASHINGTON , *) IN OPERATING 

resets the DESTINATION component of every entry to 
the value “WASHINGTON.” 


* 
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The central dynamic feature of most simulation pro¬ 
grams is the processing of simulated events occurring 
either at regular intervals or at critical points in time. 
MILITRAN provides a convenient and flexible means 
of implementing both “time-step” and “critical point” 
algorithms. Full control of event structure is retained by 
the user, and automatic features may be overridden with¬ 
out system alterations. 

The basic defining statement in a MILITRAN event 
is the EVENT statement. For example, 

CONTINGENT EVENT ARRIVE ( (ARRIVAL TIME, ARRIVING CAR), 8) 

defines the beginning of a block of statements which 
perform the processing associated with the arrival of cars 
at a given point. In addition, the same statement defines 
a list of parameters which distinguish one occurrence of 
the event from another. An END statement defines the 
end of the event processing block. Any number of events 
may be included in the program, and the processing asso¬ 
ciated with each event may take any form. At each 
occurrence of the event, the system clock (TIME) is 
automatically updated. Similarly, the entry containing 
parameters relating to the particular occurrence is located 
by the system variable INDEX. These automatic up¬ 
dating processes are triggered by the NEXT EVENT 
statement. 

The selection of events in their proper simulated order 
is accomplished as follows: 

1. By convention, the first component of each entry 
in an event list is considered to be the time at which 
the event will occur. 

2. Upon execution of the NEXT EVENT statement, 
all event lists are examined to find the entry having 
the smallest time component greater than or equal 
to TIME. 

3. TIME is set to the value of the chosen entry’s time 
component; INDEX is set to the position of that 
entry within its list. 

4. Control is transferred to the statement block asso¬ 
ciated with the list containing the chosen entry. 

Several implications arise directly from this convention. 
First, every entry in every event list represents the poten¬ 
tial occurrence of an event. Events may be scheduled or 
cancelled by means of simple list processing statements. 
Any event may cause or inhibit any other event by this 
means. Since the selection process is initiated specifically 
by the NEXT EVENT statement, several events may 
share blocks of coding. An unconditional transfer of 
control from one event to another does not violate system 
rules. The system clock (TIME) may be altered by the 
user if that is desired, and no disruption of the automatic 
event sequencing will result. Additional degrees of free¬ 
dom are provided by the PERMANENT EVENT state¬ 
ment and modified NEXT EVENT statements. These 
permit planned variations in the “natural” event se¬ 
quence. 
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General Features 

Although much of the processing involved in a simula¬ 
tion program appears similar to that used in strictly 
computational codes, significant differences of a general 
nature occur. These differences must be considered in 
designing a simulation language, and have been an inte¬ 
gral factor in the development of MILITRAN. We have 
already mentioned several general features: sixty-char¬ 
acter identifiers, ten-dimensional arrays, and the use of 
objects as subscripts. Each of these features contributes 
heavily to the elimination of artificial coding “tricks” and 
to increased communication between programmer and 
analyst. 

The iterative processes in a simulation program often 
involve incrementation and termination criteria which 
cannot be expressed in the usual algorithmic language. 
The MILITRAN DO-loop form allows modification of 
termination criteria, increment values, and even the index 
itself within the iteration. Further, exit from the loop may 
be made at any point without loss of current values, and 
indices are defined even after normal exits. A second 
form of the DO statement permits iteration over all mem¬ 
bers of a class to be specified in a convenient and concise 
manner. Both forms of DO-loop may be nested to any 
depth. 

Several MILITRAN features reduce considerably the 
need for recompilation of a program: full diagnostics are 
produced by a single compiler run; the processor accepts 
mixed-mode expressions wherever contextual meaning 
is clear, thus eliminating recompilation due to missing 
(and unnecessary) decimal points; allocation of storage 
at running time eliminates recompilation for adjustment 
of dimensions. 

MILITRAN provides extensive cross-referenced com¬ 
piler listings, and further aids self-documentation efforts 
by permitting comments at any point . . . even within a 
statement. 

Further Information 

Three MILITRAN manuals are available to qualified 
requesters through the Defense Documentation Center 
(DDC), and are offered for sale through the Clearing¬ 
house for Federal Scientific and Technical Information 
(CFSTI), Springfield, Virginia 22151. The manuals and 
their prices from CFSTI are: 

1. MILITRAN Reference Manual (AD 601-794), 
$2.25 

2. MILITRAN Operations Manual for IBM 7090/ 
94 (AD 601-795), $2.00 

3. MILITRAN Programming Manual (AD 601- 
796), $3.50 

Other inquiries concerning MILITRAN should be 
directed to the Special Projects Department, 

GULTON SYSTEMS RESEARCH GROUP, INC. 

1901 N. Fort Myer Drive 

Arlington, Virginia 22209 


MILITRAN Statements 

Environment Declarations 

REAL m(ii, i 2 ,..., i k ),..., n m (ii, i 2 , — , ij) 

INTEGER m(ii, i 2 ,..., i k ),..., n m (ii, i 2 ,..., ij) 

LOGICAL m(ii, i 2 ,..., i k ), • •., n m (ii, i 2 ,..., ij) 

OBJECT m(ii),n 2 (i 2 ),...,n m (i m ) 

PROGRAM OBJECT m(ii, i 2 ,..., i k ),..., n m (ii, i 2 ,..., L) 
CLASS (c) CONTAINS ai, a 2 ,..., a m 
NORMAL MODE mi(ai, a 2 ,..., a k ), m 2 (bi, b 2 ,..., b r ) 
VECTORN ( (ai,a 2 ,...,a i ),d 1 ,d 2 ,...,d i ) 

COMMON m, n 2 ,..., n { 

Substitution Statement 
a = b 

Control Statements 
GO TOs 
PAUSE j 
STOP 

IF (b),s t ,s f 
UNLESS (b),s f ,s t . 

DO (s) UNTIL b, n = ei,e 2 
DO (s) FOR a.IN.b 
CONTINUE 

List Processing Statements 
LIST n ( (ci, c 2 ,..., Cj), d) 

LENGTH (n) 

RESET LENGTH (n) to p 
PLACE (ei,e 2 ,..., ei ) IN n 
REMOVE ENTRY n(k) 

PLACE ENTRY m(j) IN n 

REPLACE ENTRY n(k) BY (ei,e 2 ,... ,e t ) 

REPLACE ENTRY n(k) BY ENTRY m(j) 

REMOVE (bi, b 2 ,..., bj) FROM n 
REPLACE (bi, b 2 ,..., bj) BY (ei,e 2 ,...,e t ) IN n 
REPLACE (bi,b 2 ,...,bj) BY ENTRY m(j) IN n 
MINIMUM INDEX (n(bi, b 2 ,..., b t , b x ), s) 

RANDOM INDEX (n(bi, b 2 ,..., b i? b x ), s) 

Event Statements 

PERMANENT EVENT n( (ai, a 2 ,..., a*), d) 
CONTINGENT EVENT n( (ai, a 2 ,..., a*), d) 

NEXT EVENT 

NEXT EVENT (m, n 2 ,..., ) 

NEXT EVENT EXCEPT (m, n 2 ,..., n t ) 

END 

END CONTINGENT EVENTS (s) 

Procedure Statements 
PROCEDURE n 
PROCEDURE n(ai, a 2 ,..., a n ) 

EXECUTE n 

EXECUTE n (ai, a 2 ,..., a n ) 

RETURN 
RETURN a 

Input-Output Statements 

FORMAT (Format Specification) 

READ (t, s) List 
WRITE (t,s) List 
READWRITE (ti,si, t 2 , s 2 ) List 
BINARY READ (t) List 
BINARY WRITE (t) List 
END FILE RETURN (s) 

END RECORD RETURN (s) 

BACKSPACE (t) 

BACKSPACE FILE (t) 

END FILE (t) 

REWIND (t) 

UNLOAD (t) 
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MILITRAN CODING FORM 
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STATEMENT LABEL ^ 

1 6 III 

MILITRAN STATEMENT 

2 ,13 17 22 27 32 37 42 47 52 57 62 67 72 

.... 1. 
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, , ,PR<PFI,T PER, TRUE,*, CQ,ST PER SPACE PER DAY, 

T/VPUT, 
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.... 1 .... . 

peace, (eay,s per ruk), ta erd <pf, ruk , 

.... 1. 

Peace, (- (rerdqm) /,ARRTv,ai rare) ry arrival , 

.... 1. 

A EXT ,E VERT, ... , 6TMRYP TRRA, BEQr/JS 1 

.... 1 ..... . 

f 'C<PHTTRC.E/Vr, EVERT ARRTWAE ,(( ARERVA*- ;rz»fE)*r O 

L ‘. . , i .. 

IF(lE/VCTR (SER VICE QUEUE),.££• R RACES),,, (YEKJ TRU,0 K , 
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A EXT ,TRUCK 
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■ . . ■ 1 . k . . . 

EUD Tpps state/hert is, ALS4>, tutE pPRerEP AS, ‘REX,r evert' 

. . . . 1 .. t . . . 

CPATTRCERT, E VERT SERVICE'QUEUE, ((SER VTCE, 7~T/ffE,), SP,AC&s), 

.... 1 ..... . 

Pfi<t>EX,T =• PROFIT, *■ PPpFZT- ,P£R TRUCK , 

.... 1 . ... 

PE/A<t Vf E/VTR y Service, queur (TupEx) , , , , , 

.1. 

£ «P. .., . . . . 

.... 1. 
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.... 1 . ... 

tdRZTE, (C y PUT PUT,) PRQFTT - SPAC,ES*TT,ME* Cp,ST PER SPARE PER DAY 

tuTPUjr 

FARMAr ,(?Hx .= {?.- *), . . , . . . . ...... , 

. . . . 1 . t . . . 

STOP . .... i ... . ..... . , . . 

.... 1. 
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MILITRAN Features 

Event Processing 

• Programmed alteration of natural event sequence 
can be specified at any time. 

• Permits any timing convention without system mod¬ 
ification. 

• Attacker, target and critical parameters located 
automatically. 

Object/Class Definition 

• Unlimited association of objects within a class 
structure. 

• Automatic association of data with objects. 

• Free manipulation of object identifiers as variables. 

• Input/output of object identifiers. 

List Processing 

• List structure permits several components to be 
associated directly. 

• A list may be processed as a whole; list entries may 
be accessed with or without reference to objects. 

• Full capability to place, remove, replace, or modify 
list entries; entry selection by position or any set 
of logical conditions on any or all components. 

Arrays 

• Number of dimensions in an array limited only by 
storage capacity. Ten-dimensional arrays are en¬ 
tirely possible. 

• Dimensions may be expressions involving parame¬ 
ters to be supplied at load-time. 

• Subscripts may take the form of any expression 
and may be nested to any depth. 

General 

• Identifiers may be up to 60-characters in length. 

• DO-loops are controlled by logical expressions; 
indices may be altered within the loop; transfers 
to and from loops are not restricted. 

• Debugging time is reduced to a minimum by a full 
set of diagnostics and a complete cross-reference 
system. 

• All levels of diagnostics are issued in a single com¬ 
piler run. 
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